kvm: fix direct-download live storage migration - #14101

Reopened as a fresh PR after #13084 was auto-closed by GitHub following a history correction on the branch (author identity fix, no code/content change — verified via unchanged tree hashes). Carrying over the original description below; #13084 has the prior review history from @nvazquez and the successful packaging run.

Description

This PR fixes live storage migration for KVM instances whose migrated volumes are backed by direct-download templates.

The problematic path is linked-clone live storage migration. For that mode, libvirt expects the rest of the backing chain to already exist on the destination and to match the source. That assumption is not safe for direct-download backed volumes, where the template may have been bypassed or staged directly on primary storage. When such a volume is part of the actual migration set, this PR forces the KVM migration request to use full-clone storage migration instead.

A few related edge cases are handled in the same path:

• the full-clone decision ignores volumes that are skipped from the migration request, such as same-pool PowerFlex volumes or volumes rejected by shouldMigrateVolume
• VolumeDataFactoryImpl now carries the template directDownload flag consistently across its getVolume(...) variants, including volumes whose template was removed later
• copied template references are updated instead of blindly persisted, and missing source references now fail with a useful error instead of a later NPE
• ModifyTargetsCommand failures preserve the agent error details and empty connected-path answers fail with a clearer exception

This keeps the change scoped to the KVM storage migration bug. It does not try to mix linked-clone and full-clone per disk, since the current KVM/libvirt migration command chooses the storage migration mode for the VM migration request as a whole.

Types of changes

• Breaking change (fix or feature that would cause existing functionality to change)
• New feature (non-breaking change which adds functionality)
• Bug fix (non-breaking change which fixes an issue)
• Enhancement (improves an existing feature and functionality)
• Cleanup (Code refactoring and cleanup, that may add test cases)
• Build/CI
• Test (unit or integration test code)

Feature/Enhancement Scale or Bug Severity

Feature/Enhancement Scale

• Major
• Minor

Bug Severity

• BLOCKER
• Critical
• Major
• Minor
• Trivial

Screenshots (if appropriate):

N/A. This is a backend KVM storage migration fix.

How Has This Been Tested?

Targeted unit tests:

mvn -pl engine/storage/datamotion,engine/storage/volume -am \
  -Dtest=AncientDataMotionStrategyTest,KvmNonManagedStorageSystemDataMotionTest,StorageSystemDataMotionStrategyTest,VolumeDataFactoryImplTest \
  -DfailIfNoTests=false -Dsurefire.failIfNoSpecifiedTests=false test

Result: 74 tests run, 0 failures, build success.

Manual verification was also done in a two-host KVM 4.22 test environment:

• registered a direct-download Rocky Linux template
• deployed an instance from that template
• live migrated the instance with storage from host A to host B
• live migrated it back from host B to host A
• confirmed the VM stayed running after each migration
• confirmed management logs showed the expected full-clone fallback for the direct-download backed volume

How did you try to break this feature and the system with this change?

Covered the boundary cases that are most likely to regress this path:

• mixed migration requests with a direct-download volume and a normal volume
• direct-download volumes that are skipped and should not force the rest of the request to full clone
• existing and missing copied template references
• destination template references whose backing path differs from the source backing path
• ModifyTargetsCommand returning a generic failed Answer
• ModifyTargetsAnswer returning no connected paths
• volumes with no template ID, to avoid unnecessary template lookups